home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20020314-20021006
/
000083_dkcombs@panix.com_Mon May 20 18:04:56 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2002-10-06
|
1KB
|
44 lines
Article: 13377 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!panix3.panix.com!not-for-mail
From: dkcombs@panix.com (David Combs)
Newsgroups: comp.protocols.kermit.misc
Subject: REGET not as clever as RESEND?
Date: 20 May 2002 17:47:09 -0400
Organization: PANIX -- Public Access Networks Corp.
Lines: 28
Message-ID: <acbqst$bj2$1@panix3.panix.com>
NNTP-Posting-Host: panix3.panix.com
X-Trace: reader1.panix.com 1021931059 14085 166.84.1.3 (20 May 2002 21:44:19 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Mon, 20 May 2002 21:44:19 +0000 (UTC)
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13377
RESEND does a pretty good job of almost instantly
recovering up to the %done that it had been
at when the prior transfer crapped out.
REGET seems to me so far to do a much POORER
job of doing that, like recovering up to only
maybe 1/3 of how far the prior get had gotten,
and then rereading a whole lot of stuff that
had (presumably) already been read in the prior
kermit-run.
Am I the only one who has seen this?
(NOTE: I was using -i)
QUESTION: what is the SIZE of the blocks
that kermit sends? (by default)
---
Now, kermit registers 100%, but starts getting
errors (two per second) trying to get the last
several bytes, it seems.
Thanks,
David